2018-04-19 DKIM, spam control, and bulk mailers

DKIM is useful for both whitelisting (we want to accept mail that is really from paypal.com) and blacklisting (we want to reject forged mail from paypal.com). In the case of paypal, they publish a DMARC record:

"v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com"

so we can (local policy) whitelist mail that is DKIM signed by paypal.com, and can (per paypal's published policy) blacklist mail that is not DKIM signed (or SPF PASS) by paypal.com.

That works nicely for folks that publish DMARC records, but there are others that we want to whitelist, where the signing domain has no relationship to the RFC5322 header from domain. For example, mail from American Airlines aa.com is signed by amrcorp.onmicrosoft.com. We can use the dnsbl milter to whitelist that mail by

aa.com  require_signed amrcorp.onmicrosoft.com;

This is a local policy sort-of-like-dmarc constraint that mail from aa.com is whitelisted if signed by amrcorp.onmicrosoft.com, and it is otherwise blacklisted. There are many domains that are dkim signed by *.onmicrosoft.com, which seems to be the default for Office 365 domains that have not generated their own DKIM keys. This is similar to the Google Apps folks - we want to whitelist lacity.org but their mail is signed by lacity-org.20150623.gappssmtp.com.

You might want to whitelist (or blacklist) mail from a domain that uses a bulk mailer like Constant Contact, MailChimp, or others.

AWeber signs their outgoing mail with header.d=aweber.com.

Bluehornet sometimes signs with a DKIM key in the customer domain, and sometimes signs with a key in bluehornet.com. Consider mail from njsba.com via bluehornet. Some of the mail is signed as "s=s1024-1.bh, d=njsba.com" but that mail always fails signature verifications. Other mail from njsba.com is signed as "s=s1024-1.bh, d=bluehornet.com" and that mail always passes signature verification. They are not verifying that the customer publishes the proper key.

Constant Contact has at least three classes of customer. They can sign with a DKIM key in the customer domain, or in a customer specific subdomain of ccsend.com, or in the shared auth.ccsend.com domain.

CreateSend signs with one of two DKIM keys, in the cmail19.com and cmail20.com domains. Of course they could add more of those. Any individual sender may be signed with either of those keys.

ExactTarget outgoing mail is either unsigned, or signed with a DKIM key in the customer domain.

iContact outgoing mail is signed with keys in any of icontactmail*.com, but any individual sender seems to be always signed with the same domain.

MailChimp, for many of their customers, uses essentially random signing domains across at least three different second level domains. That makes their DKIM signatures more difficult to use for white or blacklisting. The dnsbl milter can now whitelist with wildcarded signers such as "mandrillapp.com,*.mcsignup.com,*.mcsv.net,*.rsgsv.net,*.mcdlv.net".

filmadelphia.org signer mail74.us4.mcsv.net
filmadelphia.org signer mail228.suw16.rsgsv.net
filmadelphia.org signer mail228.suw16.rsgsv.net
filmadelphia.org signer mail9.us4.mcsv.net
filmadelphia.org signer mail240.atl61.mcsv.net
filmadelphia.org signer mail51.us4.mcsv.net
filmadelphia.org signer mail182.atl121.mcsv.net
filmadelphia.org signer mail1.suw11.mcdlv.net
filmadelphia.org signer mail139.atl61.mcsv.net
filmadelphia.org signer mail35.atl51.rsgsv.net
filmadelphia.org signer mail38.atl161.mcsv.net
filmadelphia.org signer mail13.atl11.rsgsv.net

However, they do have some customers where they sign with a DKIM key in the customer domain.

Mailgun outgoing mail is either unsigned, or signed with a DKIM key in the customer domain.

Mandrill (now owned/run by MailChimp?) signs much of their outgoing mail with two DKIM keys, one in mandrillapp.com and the other in the customer domain.

Marketo signs their outgoing mail with a key in the customer domain, or in one of (mktroute.com, mktomail.com, mktdns.com, mktosender.com).

Sendgrid signs almost all of their outgoing mail with a DKIM key in the customer domain. However, they don't verify that the key they are using for signing is actually published in the customer domain. smtpapi._domainkey.email.petersen.org does not exist.

Sendlabs signs (almost?) all of their outgoing mail with a DKIM key in the customer domain.